home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 5302 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.8 KB

  1. Path: munta.cs.mu.OZ.AU!fjh
  2. From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson)
  3. Newsgroups: comp.lang.java,comp.lang.eiffel,comp.lang.misc,comp.lang.c++
  4. Subject: Re: Constness in languages (Re: java weaknesses and peculiararities)
  5. Date: 3 Feb 1996 16:42:47 GMT
  6. Organization: Comp Sci, University of Melbourne
  7. Message-ID: <4f03a8$don@mulga.cs.mu.OZ.AU>
  8. References: <30FBED5F.28B8@achilles.net> <4dj4t4$a4@kai.com> <4e6dtm$si5@gaia.ns.utk.edu> <9602901.11916@mulga.cs.mu.OZ.AU> <4ej1eo$s7@stc06.ctd.ornl.gov>
  9. NNTP-Posting-Host: munta.cs.mu.oz.au
  10.  
  11. mbk@jt3ws1.etd.ornl.gov (Kennel) writes:
  12.  
  13. >Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
  14. >> But types also allow you to do more.  Using postconditions only allows
  15. >> you to ensure the constness of references passed to a routine.  Using
  16. >> types also allows you to ensure the constness of references returned
  17. >> from a routine.
  18. >
  19. >Why do you always want to do that?  That's putting restrictions on what
  20. >the caller can do with a thing.
  21.  
  22. Sure, you don't *always* want to do it, but often it is useful.
  23. Being able to add restrictions is in general a useful thing.
  24.  
  25. >The most common use of "const" you want to ensure that the routine didn't
  26. >do anything nasty behind your back.  
  27. [...]
  28. >Yes there are other uses for const, but I think those are better
  29. >handled by regular types. 
  30.  
  31. I don't think so.  This has several problems.
  32.  
  33. One potential problem is that it requires multiple inheritence.
  34. If a foo is-a bar, then a const-foo is-a const-bar.
  35.  
  36.          const-bar
  37.           /    \
  38.         const-foo   bar
  39.           \    /
  40.             foo
  41.  
  42. Note that you want to use implementation inheritence to
  43. implement this, not just interface inheritence.  So if your language
  44. does not support multiple implementation inheritence, then you will
  45. have serious trouble.
  46.  
  47. A more general problem is that it breaks encapsulation: the user of
  48. `foo' who decides that they need a `const-foo' is in trouble if the
  49. designer of `foo' didn't foresee that need.
  50.  
  51. A final drawback is that this technique generally requires lots
  52. of boring, repetitive coding.
  53.  
  54. >> >The fundamental difference between pre- and post-conditions is that
  55. >> >preconditions put restrictions the caller, whereas postconditions
  56. >> >put restrictions on the callee.
  57. >
  58. >> Right.  And types can put restrictions on both.  Which is exactly what
  59. >> you want.
  60. >
  61. >The example that started this thread was a demonstration of when such
  62. >a notion had undesirable consequences:  forcing a needless massive
  63. >"reconsting" of a program or preventing "const" from being used in a
  64. >natural way. 
  65.  
  66. I didn't see that example; perhaps you could repost it or a similar
  67. example?
  68.  
  69. >> Anyway, postconditions aren't sufficient, because if you want to pass a
  70. >> reference to an object which is shared with another thread or which is
  71. >> stored in ROM) you also need to be able to prevent intermediate
  72. >> modifications.  Types will allow you to do that; postconditions won't.
  73. >
  74. >But we already have types:  make an interface "NON_MODIFIABLE_FOOBAR"
  75. >(or use Eiffel's qualified export capability) that says exactly what is
  76. >and what isn't modifable.   I don't know about C++ but in Eiffel or Sather
  77. >it's perfectly OK to hide modification routines of attributes from some 
  78. >clients via interfaces. 
  79.  
  80. Yes, but doing this manually has all the problems I described above.
  81.  
  82. >And you have the full power of normal types in an integrated whole 
  83. >instead of the special "const/non-const" cross "user_defined_types".
  84.  
  85. I agree that making the relationship between const and non-const too
  86. special is undesireable.  It should be as close as possible to the
  87. relationship between base class and derived class.  But I do think
  88. that "const" is sufficiently useful to warrant special syntactic support.
  89.  
  90. >> How is the compiler going to know which variables are aliased to which
  91. >> other ones?
  92. >>
  93. >> Are you supposing that the compiler should be required to do global
  94. >> aliasing analysis?  If so, what level of precision of analysis would
  95. >> you require?
  96. >>
  97. >> That seems to me to be a very big problem for your approach.
  98. >
  99. >> You are presuming that the compiler has perfect aliasing information
  100. >> at compile time.  But this is not the case in any of the languages
  101. >> under discussion.
  102. >
  103. >Yes, you're right about that.  But C doesn't even try, right?
  104.  
  105. No; but in C/C++, the type system carries around enough information
  106. to ensure that aliasing analysis is not needed in order to prove
  107. const-correctness, so the compiler doesn't need to try.
  108. (That is, it doesn't need to try for the purposes of checking `const';
  109. alias analysis may still be useful for optimization, of course.)
  110.  
  111. >I think aliased const modifications would have to be moved to a "warning"
  112. >as not all could be detectable. 
  113.  
  114. What exactly do you mean by that?  Would the compiler warn about every
  115. assignment that might possibly modify an aliased const?  If so, you
  116. would get far too many spurious warnings; that would not be practical.
  117.  
  118. Or would the compiler only warn if it was sure an assignment was going
  119. to modify an aliased const?  In that case, the compiler wouldn't be
  120. able to provide useful guarantees at compile time.  The constness
  121. annotations would be not be much of an improvment over ordinary
  122. runtime-checked post-conditions.
  123.  
  124. >> I don't understand.  In C++, "constifying" one routine will not require
  125. >> any changes to its callers either, will it?
  126. >
  127. >In the original example it did: you would have had to declare or
  128. >make something a "const" type if I remember right.
  129.  
  130. Again, I missed the example, so if you could repost it, I'd be most obliged.
  131.  
  132. But I don't think there are any problems that couldn't be solved if the
  133. caller was written correctly; the could be ensured by making `const'
  134. the default and requiring an explicit `var' for variables, or by
  135. getting compilers to warn about places where `const' ought to be
  136. added.
  137.  
  138. --
  139. Fergus Henderson                 WWW: http://www.cs.mu.oz.au/~fjh
  140. fjh@cs.mu.oz.au                  PGP: finger fjh@128.250.37.3
  141.